重要度基盤のリッチメディア提供システム及び方法と、これに適用されるサーバー

专利摘要:
本発明は、ネットワーク環境に適応的なリッチメディアサーバー、リッチメディア伝送システム及びリッチメディア伝送方法を開示する。本発明のリッチメディアサーバーは、リッチメディアを要請する端末装置と通信するためのインターフェース部；上記要請に対応する少なくとも１つのメディアを処理するメディア処理部；上記メディア処理部から出力される少なくとも１つのメディアを上記端末装置に提供するためにリッチメディアとしてエンコーディングして上記インターフェース部へ出力するリッチメディアエンコーディング部；及び上記リッチメディアの再生情報に基づき上記リッチメディアを構成するメディアに対する重要度を判別して、上記重要度判別結果を基に上記少なくとも１つ以上のメディアに対する伝送プロセッシングを変換するように上記メディア処理部と上記リッチメディアエンコーディング部のうちの少なくともどちらか１つを制御する制御部；を含む。
公开号:JP2011507316A
申请号:JP2010533955
申请日:2008-08-18
公开日:2011-03-03
发明作者:ユン リー、ジュン
申请人:エスケーテレコム株式会社Ｓｋ Ｔｅｌｅｃｏｍ Ｃｏ．，Ｌｔｄ．；
IPC主号:H04N7-173

专利说明:

[0001] 本発明は、リッチメディアの伝送方式に関し、より詳しくは、リッチメディアの伝送にあたってネットワーク環境及びリッチメディアを構成するメディア等の重要度を考慮してネットワーク環境に適した最適のリッチメディアを伝送し得るリッチメディアサーバー、リッチメディア伝送システム、及びリッチメディア伝送方法に関する。]
背景技術

[0002] 超高速インターネット有線通信網またはＩＭＴ２０００などの無線通信網による通信システムを基盤にしてマルチメディアコンテンツサービスを提供する方法及びシステムが注目されている。]
[0003] 特に、有線または無線の端末装置を通して音声及び文字だけでなく、静止画像及び動画像を送受信できる機能、ＭＰ３ファイルのような音楽ファイルを授受できる機能が、端末装置への追加又は外部機器との連結を通して具現されることにより、有線または無線でマルチメディアコンテンツファイルを送受信するための技術的基盤が構築されており、これに伴ない、消費者が自らマルチメディアコンテンツファイルを製作して有無線通信網に配信するための技術的基盤も整えられている。]
[0004] なお、有線または無線の使用者端末装置は、マルチメディアコンテンツファイルとして提供される無数のメディア（例えば、静止画像または動画像）が全て再生可能なメディア再生関連性能を備えることはできないため、再生不可能なメディアを生じさせざるを得ない。]
[0005] メディアの種類だけを見ても、テキスト、静止画像、オーディオ及び動画像など無数にあり、上記オーディオ関連のメディア類を再生するためのファイルを拡張子別に羅列すると、ｍｐａ、ｍｐ３、ｍｐ２、ｗｍａ、ｗａｖなどがあり、上記動画像関連のメディア類を再生するためのファイルを拡張子別に羅列すると、ｗｍｖ、ａｖｉ、ｄｉｖｘ、ａｓｆ、ｍｐｇなどがある。]
[0006] このように、メディアの種類が無数にあることから、使用者端末装置がこれらを全て再生するためのコーデックを具備するのは容易なことではない。]
[0007] 更に、性能の面において使用者端末装置は、通常、多様なメディアを再生処理し得る処理能力がパーソナルコンピューター（ＰＣ）よりは相対的に劣ることから、コーデックの具備が容易でないことに加えて、該当メディアを端末画面にディスプレイするまでのハードウェア性能の面においても、その不足した処理能力のため再生可能なメディアは限定されざるを得ない。]
[0008] 上記使用者端末装置でのハードウェア的な処理能力について付言すれば、単一メディアを再生する場合よりは、少なくとも２つ以上のメディアを再生する場合に性能の限界に当面することが頻繁に起こる。]
[0009] 通常、少なくとも２つ以上のメディア（例えば、動画像）を再生する使用者端末装置は、圧縮された動画像ファイルを保存するメモリー、メモリーに保存された第１の動画像ファイルを圧縮解除して出力する第１のデコーダー、メモリーに保存された第２の動画像ファイルを圧縮解除して出力する第２のデコーダー、第１のデコーダー及び第２のデコーダーから出力される動画像フレームを合成して出力する画像処理部、画像処理部から出力されるデータをディスプレイするディスプレイ部、及びメディア再生のためのプロセッシングを行なう制御部を通してメディアの再生を実行することになる。]
[0010] メモリーには、１個あるいは複数個のフラッシュメモリー、ハードディスク、光ディスク保存装置またはこれらの組み合わせなど様々な保存装置が挙げられる。]
[0011] 第１のデコーダー及び第２のデコーダーは、各々が複数のフォーマットの圧縮されたファイルを再生し得る柔軟な構造のデジタル信号処理器として具現される。ＭＰＥＧ−４、Ｈ．２６３、ＭＰＥＧ−２など様々なフォーマットのうちの１つあるいは２つ以上が支援され得る。]
[0012] 従って、これら両デコーダーは、同時に動作しながら、それぞれ相異なるフォーマットの動画像ファイルを再生することもできる。]
[0013] それぞれのデコーダーは、指定された動画像ファイルに対して指定された時間的位置から再生を開始する。また、それぞれのデコーダーは、高速再生、低速再生などの機能を有する。]
[0014] このような機能を持つデコーダーは、商用化されて提供されてきており、これと関連したコーデックは、それぞれのファイルを圧縮解除して例えば、ＹＵＶまたはＲＧＢのような標準フォーマットの画像フレームを出力する。]
[0015] 画像処理部は、入力される画像フレームを各々拡大したり縮小したりすることができ、２つの画像を合成することもできる。]
[0016] 例えば、２つの動画像は各々縮小されて画面分割で表示されることができる。つまり、１つの動画像フレームがメイン画面として全体画面に表示され、もう１つの動画像フレームは縮小されてＰＩＰ（Ｐｉｃｔｕｒｅ−Ｉｎ−Ｐｉｃｔｕｒｅ）の形式で表示されることができる。]
[0017] しかし、このような従来技術による使用者端末装置は、メディア、特に２つの動画像を同時に再生して端末画面上に出力することは可能であるものの、より多くの動画像を同時に再生するためにはより一層優秀な性能で具現されなければならず、また、あらゆる使用者端末装置が２つの動画像を端末内での動作を通して再生できるように具現されているわけではないため、端末内で再生できない動画像が発生せざるを得ないとの問題点がある。]
[0018] 更に、サーバー側から使用者端末装置へ提供する所定のメディア提供基盤のサービスにおいて構成要素となる少なくとも１つ以上のメディアが使用者端末装置に伝えられる間に、伝送環境によって流失されるメディアが発生すれば、全体的なサービスの実行に大きな影響を及ぼすことになるため、該当メディアを再伝送したり、損失が発生しても復旧可能なようにエラー訂正コードを伝送するのが一般的である。]
[0019] だが、メディア損失を復旧するために反射的にエラー訂正コードを伝送したり該当メディアを再伝送したりすることは、通信環境における帯域幅やサービス運用の側面で効率的なことではないとの問題点がある。]
[0020] かかることから、上記のような問題点を克服し得る方案が要求されている。]
発明が解決しようとする課題

[0021] したがって、本発明は上記の問題点を解決するために創出されたものであって、本発明の目的は、メディア提供基盤のサービスの提供を受けるために接続する使用者端末装置に応答するサーバーが、使用者端末装置に対するメディア再生関連データに基づき該当する少なくとも１つ以上のメディアを抽出した後、このメディアに対する重要度を判別し、上記重要度の判別結果を基に上記少なくとも１つ以上のメディアに対する伝送プロセッシングを変換して、重要なメディアのみ伝送するか、あるいは先ずは重要なメディアを伝送し、重要度の劣るメディアは追って伝送する等してメディアの伝送方法を制御する、重要度基盤のメディア提供システム及び方法と、これに適用されるサーバーを提供することにある。]
[0022] また、本発明の他の目的は、メディア提供基盤のサービスの提供を受けるために接続する使用者端末装置に応答するサーバーが、使用者端末装置に対するメディア再生関連データに基づき該当する少なくとも１つ以上のメディアを抽出した後、メディア提供基盤のサービスを実行するか、或いは使用者のサービス利用の面で抽出した上記少なくとも１つ以上のメディアに対する重要度を判別し、重要度別に分類されるそれぞれのメディアに対応してエラー訂正コードの量を差別的に調節し使用者端末装置へ伝達する、重要度基盤のメディア提供システム及び方法と、これに適用されるサーバーを提供することにある。]
課題を解決するための手段

[0023] 上記目的を達成するための本発明によるリッチメディアサーバーは、ネットワークを通してリッチメディアを伝送するリッチメディアサーバーにおいて、リッチメディアを要請する端末装置と通信するためのインターフェース部；上記要請に対応する少なくとも１つのメディアを処理するメディア処理部；上記メディア処理部から出力される少なくとも１つのメディアを上記端末装置に提供するためにリッチメディアとしてエンコーディングして上記インターフェース部に出力するリッチメディアエンコーディング部；及び、上記リッチメディアの再生情報に基づき上記リッチメディアを構成するメディアに対する重要度を判別し、上記重要度の判別結果を基に上記少なくとも１つ以上のメディアに対する伝送プロセッシングを変換するように、上記メディア処理部と上記リッチメディアエンコーディング部のうちの少なくとも１つを制御する制御部；を含む。]
[0024] そして上記制御部は、上記リッチメディアに含まれるそれぞれのメディアに対して、上記リッチメディアの構成において必須要素なのか否か、上記リッチメディアで表示される持続時間、再伝送の可・不可、上記それぞれのメディアを参考にしたり活用する参照メディアの個数、及び製作者が製作当時に指定した製作者指定重要度のうちの少なくとも１つに基づいて、上記それぞれのメディアの重要度を判別することが望ましい。]
[0025] また上記制御部は、下記のような優先順位指数算出数式に基づいて上記リッチメディアに含まれる各メディアの優先順位指数を算出し、上記優先順位指数が高いメディアを重要度が高いものと判別することが望ましい（ここで、Ｗ１〜Ｗｎ、ｆ１〜ｆｎは、各変数に対する重要度計算関数である）。]
[0026] 優先順位指数＝｛Ｗ１（持続時間）＋Ｗ２（参照メディアの個数）＋Ｗ３（製作者指定重要度）｝＊ｆ１（必須該否）＊ｆ２（再伝送の可・不可）]
[0027] そして、上記制御部は、上記ネットワークの帯域幅別に上記リッチメディアの伝送容量を調節するための伝送容量情報を含む伝送調節テーブルを予め保存し、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づいて上記メディアの伝送容量を調節することが望ましい。]
[0028] また上記伝送調節テーブルは、上記ネットワークの帯域幅別に上記メディアの伝送ビット率を調節するための伝送ビット率情報を含み、上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づいて上記メディアのビット率を調節するように上記メディア処理部を制御することが望ましい。]
[0029] そして上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づき、上記ネットワークの帯域幅に該当する上記伝送ビット率情報に対応して上記メディアのビット率を上げたり下げたりするように上記メディア処理部を制御することが望ましい。]
[0030] また上記伝送調節テーブルは、上記ネットワークの帯域幅別に上記メディアを伝送するか否かを選択するための伝送選択情報を含み、上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルの上記伝送選択情報に基づき上記メディア処理部から出力される少なくとも１つのメディアのうち重要度の低い少なくとも１つのメディアを除去して上記リッチメディアとしてエンコーディングするように上記リッチメディアエンコーディング部を制御することが望ましい。]
[0031] そして上記伝送調節テーブルは、上記ネットワークを通しての上記リッチメディアの伝送が遅れる伝送遅延時間の限界遅延時間情報を含み、上記制御部は、上記ネットワークの伝送遅延時間が上記伝送調節テーブルの限界遅延時間情報以上である場合、上記メディア処理部から出力される少なくとも１つのメディアのうち重要度の高いメディアから重要度の低いメディアの順にエンコーディングして順次に出力するように、上記リッチメディアエンコーディング部を制御することが望ましい。]
[0032] また上記制御部は、重要度判別結果に応じて上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を調節することが望ましい。]
[0033] そして上記制御部は、上記少なくとも１つ以上のメディアが重要レベルのメディアである場合、上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を通信帯域幅に対応して増やすことが望ましい。]
[0034] また上記制御部は、上記少なくとも１つ以上のメディアが重要でないレベルのメディアである場合、上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を通信帯域幅に対応して減らすことが望ましい。]
[0035] そして上記制御部は、上記エラー訂正コードを含む少なくとも１つ以上のメディアの伝送率をモニターリングし、モニターリング結果を基に生成される伝送ビット率調節信号に基づき、上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を再調節することが望ましい。]
[0036] 一方、上記目的を達成するための本発明の他の一実施例によるリッチメディア伝送システムは、ネットワークを通してリッチメディアを要請する端末装置、及び上記端末装置と通信するためのインターフェース部と、上記要請に対応する少なくとも１つのメディアを処理するメディア処理部と、上記メディア処理部から出力される少なくとも１つのメディアを上記端末装置へ提供するためにリッチメディアとしてエンコーディングして上記インターフェース部に出力するリッチメディアエンコーディング部と、上記リッチメディアの再生情報に基づき上記リッチメディアを構成するメディアに対する重要度を判別し、上記重要度判別結果を基に上記少なくとも１つ以上のメディアに対する伝送プロセッシングを変換するように上記メディア処理部と上記リッチメディアエンコーディング部のうちの少なくとも１つを制御する制御部とを含んでなるリッチメディアサーバーを含む。]
[0037] そして上記制御部は、上記リッチメディアに含まれるそれぞれのメディアに対して、上記リッチメディアの構成において必須要素なのか否か、上記リッチメディアで表示される持続時間、再伝送の可・不可、上記それぞれのメディアを参考にしたり活用する参照メディアの個数、及び製作者が製作当時に指定した製作者指定重要度のうちの少なくとも１つに基づき、上記それぞれのメディアの重要度を判別することが望ましい。]
[0038] また上記制御部は、下記のような優先順位指数算出数式に基づき、上記リッチメディアに含まれる各メディアの優先順位指数を算出して、上記優先順位指数が高いメディアを重要度の高いものと判別することが望ましい（ここで、Ｗ１〜Ｗｎ、ｆ１〜ｆｎは、各変数に対する重要度計算関数である）。]
[0039] 優先順位指数＝｛Ｗ１（持続時間）＋Ｗ２（参照メディアの個数）＋Ｗ３（製作者指定重要度）｝＊ｆ１（必須該否）＊ｆ２（再伝送の可・不可）]
[0040] そして上記制御部は、上記ネットワークの帯域幅別に上記リッチメディアの伝送容量を調節するための伝送容量情報を含む伝送調節テーブルを予め保存し、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づいて上記メディアの伝送容量を調節することが望ましい。]
[0041] また上記伝送調節テーブルは、上記ネットワークの帯域幅別に上記メディアの伝送ビット率を調節するための伝送ビット率情報を含み、上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づき、上記メディアのビット率を調節するように上記メディア処理部を制御することが望ましい。]
[0042] そして上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づき、上記ネットワークの帯域幅に該当する上記伝送ビット率情報に対応して上記メディアのビット率を上げたり下げたりするように上記メディア処理部を制御することが望ましい。]
[0043] また上記伝送調節テーブルは、上記ネットワークの帯域幅別に上記メディアを伝送するか否かを選択するための伝送選択情報を含み、上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルの上記伝送選択情報に基づき、上記メディア処理部から出力される少なくとも１つのメディアのうち重要度の低い少なくとも１つのメディアを除去して上記リッチメディアとしてエンコーディングするように、上記リッチメディアエンコーディング部を制御することが望ましい。]
[0044] そして上記伝送調節テーブルは、上記ネットワークを通しての上記リッチメディアの伝送が遅れる伝送遅延時間の限界遅延時間情報を含み、上記制御部は、上記ネットワークの伝送遅延時間が上記伝送調節テーブルの限界遅延時間情報以上である場合、上記メディア処理部から出力される少なくとも１つのメディアのうち重要度の高いメディアから重要度の低いメディアの順にエンコーディングして順次に出力するように、上記リッチメディアエンコーディング部を制御することが望ましい。]
[0045] また上記制御部は、重要度判別結果によって上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を調節することが望ましい。]
[0046] そして上記制御部は、上記少なくとも１つ以上のメディアが重要レベルのメディアである場合、上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を通信帯域幅に対応して増やすことが望ましい。]
[0047] また上記制御部は、上記少なくとも１つ以上のメディアが重要でないレベルのメディアである場合、上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を通信帯域幅に対応して減らすことが望ましい。]
[0048] そして上記制御部は、上記エラー訂正コードを含む少なくとも１つ以上のメディアの伝送率をモニターリングし、モニターリング結果を基に生成される伝送ビット率調節信号に基づき、上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を再調節することが望ましい。]
[0049] また上記端末装置の要請に対応する上記リッチメディアを提供するための少なくとも１つのメディアと上記メディアを再生できる端末装置の最小スペック情報を予め保存するメディアデータベースを更に含むことが望ましい。]
[0050] そして上記端末装置は、上記リッチメディアサーバーに上記リッチメディアを要請する時、上記端末装置自体の機種情報と、上記リッチメディアを再生する再生機情報とを上記リッチメディアサーバーへ提供することが望ましい。]
[0051] また上記制御部は、上記端末装置から提供される機種情報及びリッチメディア再生機情報と、上記要請されたリッチメディアに該当するメディア等の上記最小スペック情報とを比較して、上記端末装置が上記リッチメディアを再生可能かどうかを判断し、再生可能なメディアで上記リッチメディアを生成するように上記メディア処理部を制御することが望ましい。]
[0052] 一方、上記目的を達成するための本発明のまた他の一実施例による重要度基盤のメディア提供方法は、（イ）リッチメディアサービスを要請する使用者端末装置に応答する段階；（ロ）上記要請に対応するメディア再生情報を抽出し、上記メディア再生情報に基づき上記メディア提供基盤のサービスに対応する少なくとも１つ以上のメディアを抽出し、抽出した上記少なくとも１つ以上のメディアをリッチメディアとしてエンコーディングする段階；（ハ）上記リッチメディアを構成するメディアに対する重要度を判別する段階；及び（ニ）重要度判別結果を基に上記少なくとも１つ以上のメディアに対する伝送プロセッシングを変換して上記使用者端末装置に伝達する段階；を含む。]
[0053] ここで、上記（ハ）段階は、上記メディア提供基盤のサービスにおいて必須要素なのか否か、上記使用者端末装置で再生される持続時間、関連した参照メディアの数、メディア製作段階で指定された重要レベル指数、及びメディア伝送環境によって上記少なくとも１つ以上のメディアが流失され上記使用者端末装置から再伝送の要請があった場合に再伝送が可能かどうかのうちの少なくとも１つ以上から、上記少なくとも１つ以上のメディアに対する重要度を判別することが望ましい。]
[0054] また上記（ニ）段階は、重要度判別結果に応じて上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を調節したり伝送プロトコルを設定したりすることが望ましい。]
発明の効果

[0055] 従って、本発明では、メディア提供基盤のサービスの提供を受けるために接続する使用者端末装置に応答するサーバーが、使用者端末装置に対するメディア再生関連データを基に該当する少なくとも１つ以上のメディアを抽出した後、メディア提供基盤のサービスを実行するか、或いは使用者のサービス利用パターン（形態）などを考慮して抽出した少なくとも１つ以上のメディアに対する重要度を判別し、それぞれの重要度別に分類されるメディアに対応して差別化された伝送プロセッシングを実行することにより、帯域幅の制限された通信環境において効率的に該当メディアを伝送できるだけでなく、重要度の微々たるメディアやサービス構成要素を使用者端末装置に伝達しないとしても、サービス実行における連続性が提供できるという利点がある。]
図面の簡単な説明

[0056] 図１は、本発明の一実施例によるリッチメディア伝送システムを示す制御構成図である。
図２は、本発明の一実施例によるリッチメディア伝送方法の制御フローを示す制御フロー図である。
図３（Ａ）は、本発明のリッチメディア伝送方法において伝送容量を調節する段階Ｓ６０の他の実施例を示す部分制御フロー図である。図３（Ｂ）は、本発明のリッチメディア伝送方法において他の実施例を追加する部分制御フロー図である。
図４は、本発明のまた他の実施例による重要度基盤のメディア提供システムの動作過程を示すフロー図である。] 図１ 図２ 図３ 図４
実施例

[0057] 以下、添付図面を参照して本発明の望ましい実施例について説明する。
図１は、本発明の一実施例によるリッチメディア伝送システムを示す構成図である。図１に示すように、リッチメディア伝送システムは、リッチメディアを要請する端末装置１０と、リッチメディアを生成しネットワークを通して提供するリッチメディアサーバー１００とを含む。] 図１
[0058] 端末装置１０は、ネットワークを通してリッチメディアサーバー１００に接続し、端末装置１０を使用する使用者の希望のリッチメディアをリッチメディアサーバー１００に要請する。このような端末装置１０としては、一般的なＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、携帯用端末機など多様な電子装置が挙げられる。図１では端末装置１０を単一個として示したが、ネットワークを通してリッチメディアサーバー１００に接続し得る端末装置１０は複数個存在する。] 図１
[0059] 端末装置１０を構成の面でより詳しく説明すれば、端末装置１０は、ネットワークを通してリッチメディアサーバー１００と通信するための端末側インターフェース部２と、使用者が希望するリッチメディアをリッチメディアサーバー１００に要請する端末側制御部６と、要請したリッチメディアが提供されれば、このリッチメディアを保存するメディア保存部４と、このリッチメディアを再生する再生機５とを含む。]
[0060] 端末側制御部６は、端末装置１０自体の機種情報（例：製品モデルコード）と、再生機５の支援解像度及び仕様情報を含む再生機情報とを予め保存している。そして、端末側制御部６は、リッチメディアサーバー１００にリッチメディアを要請する時、自体機種情報及び再生機情報をリッチメディアサーバー１００に提供できる。また、端末側制御部６は、使用者識別情報をリッチメディアサーバー１００に提供できる。]
[0061] リッチメディアサーバー１００は、図１に示すように、インターフェース部２０、合成処理部３０、メディアＤＢ４０、使用者情報照会部５０、及び制御部６０を含む。] 図１
[0062] インターフェース部２０は、リッチメディアを要請する端末装置１０と通信するための通信部として機能する。このようなインターフェース部２０は、端末側インターフェース部２に対応する構成であればよい。]
[0063] 合成処理部３０は、メディアＤＢ４０から少なくとも１つのメディアを抽出して、端末装置１０に提供するためのリッチメディアを生成する。このような合成処理部３０は、端末装置１０からの要請に対応する少なくとも１つのメディアを処理するメディア処理部３３と、メディア処理部３３から出力される少なくとも１つのメディアを端末装置１０に提供するためにリッチメディアとして合成／エンコーディングしてインターフェース部２０に出力するリッチメディアエンコーディング部３６とを含む。]
[0064] メディア処理部３３は、後述する制御部６０が端末装置１０へ提供するものとしえ選択した少なくとも１つのメディアをメディアＤＢ４０から抽出して、リッチメディアエンコーディング部３６で処理可能な形態に処理する。このようなメディア処理部３３は、メディアＤＢ４０から抽出したメディアがスケーラブル（ｓｃａｌａｂｌｅ）コーディングがなされた動画像である場合、リッチメディアエンコーディング部３６で処理可能な解像度、ビット率などを満足させる動画像ストリームの形態に処理する。そしてメディア処理部３３は、メディアＤＢ４０にスケーラブルコーディングのなされた動画像がなく、メディアＤＢ４０から抽出したメディアが多様なエンコーディング規格で製作された選別的な動画像である場合、これらもまた該当動画像規格に対応してリッチメディアエンコーディング部３６で処理可能な動画像ストリームの形態に処理する。また、メディア処理部３３は、メディアＤＢ４０から抽出したメディアが他のコーデックによって圧縮される必要がある場合、これを変換して動画像を生成する。よって、メディア処理部３３は、動画像及び動画像以外の静止画像、アニメーションなど比較的小さな容量を占めるメディアを、端末装置１０でリッチメディアとして再生し得るように変換できる。]
[0065] リッチメディアエンコーディング部３６は、メディア処理部３３から出力される少なくとも１つのメディアを合成して端末装置１０に提供するためにリッチメディアとしてエンコーディングしてインターフェース部２０に出力する。よって、リッチメディアエンコーディング部３６は、少なくとも１つのメディアをリッチメディア画面に合成して、要請されたリッチメディア画面を端末装置１０へ提供できる。]
[0066] ここで、リッチメディアエンコーディング部３６は、テンプレート変換機能を含むことができる。これにより、リッチメディアエンコーディング部３６は、リッチメディア画面に含まれる多様な場面情報が内包しているメディアの座標、端末装置１０の入力受信方法など、端末装置１０の機種及び再生機５の仕様によって変わる部分を考慮した適切なテンプレートに基づいてリッチメディアを構成し端末装置１０へ提供することができる。ここで、リッチメディア画面に含まれる多様な場面情報は、各メディアを抽出して処理するメディア処理部３３から提供されることができる。]
[0067] メディアＤＢ４０は、端末装置１０の要請に対応するリッチメディアを提供するための少なくとも１つのメディアを保存する。ここで、保存されたメディアの形態は、スケーラブル（ｓｃａｌａｂｌｅ）コーディングがなされた動画像、多様なエンコーディング規格で製作された選別的な動画像、静止画像、アニメーションなど多様である。そして、メディアＤＢ４０は、保存しているそれぞれのメディア別に再生可能な端末装置の最小スペック情報を予め保存している。]
[0068] 制御部６０は、端末装置１０からリッチメディアが要請されれば、その要請されたリッチメディアに該当する少なくとも１つのメディアをメディアＤＢ４０から抽出してリッチメディアを生成し端末装置１０へ出力するように、メディア処理部３３とリッチメディアエンコーディング部３６を制御する。]
[0069] 制御部６０は、リッチメディアを要請する端末装置１０から機種情報と再生機情報が入力されれば、メディアＤＢ４０に保存されている各メディア別の最小スペック情報に基づいて、要請されたリッチメディアに該当する各メディアの最小スペック情報と端末装置１０の機種情報及び再生機情報とを比較する。そして、制御部６０は、要請されたリッチメディアを端末装置１０が再生可能かどうかを判断し、再生可能なメディアを抽出してリッチメディアを生成するようにメディア処理部３３を制御する。よって、メディア処理部３３は、端末装置１０が再生し得るメディアで構成されたリッチメディアを端末装置１０に提供するために、該当メディアを抽出して処理する。]
[0070] 制御部６０は、ネットワークの帯域幅別にリッチメディアの伝送容量を調節するための伝送容量情報を含む伝送調節テーブル６５を予め保存する。そして、制御部６０は、ネットワークの帯域幅情報及び伝送調節テーブル６５の上記伝送容量情報に基づいてメディアの伝送容量を調節するように、メディア処理部３３とリッチメディアエンコーディング部３６のうちの少なくとも１つを制御する。]
[0071] より詳しく説明すると、伝送調節テーブル６５は、ネットワークの帯域幅別にメディアの伝送ビット率を調節するための伝送ビット率情報を含むことができる。]
[0072] よって、制御部６０は、現在端末装置１０と通信するためのネットワークの帯域幅情報を把握し、現在ネットワークの帯域幅情報及び伝送調節テーブル６５に基づいて、ネットワークの帯域幅に該当する伝送ビット率情報に対応して各メディアのビット率を上げたり下げたりするようにメディア処理部３３を制御する。これにより、メディア処理部３３は、メディアＤＢ４０から抽出した少なくとも１つのメディアを処理するにあたって、ネットワークの帯域幅が狭ければ、各メディアのビット率を下げて処理してリッチメディアエンコーディング部３６に提供し、ネットワークの帯域幅が広ければ、各メディアのビット率を正常維持するかビット率を上げるように処理してリッチメディアエンコーディング部３６に提供する。]
[0073] 従って、本発明によるリッチメディア伝送システムは、リッチメディアサーバー１００が制限された帯域幅を持つネットワークを通してリッチメディアを伝送する時、ネットワーク帯域幅を考慮してメディアのビット率を調節しリッチメディアを生成／伝送することによって、ネットワークの帯域幅に合わせてリッチメディアの伝送容量を調節し重要な情報を遅延や損失無しに適応的に端末装置１０へ提供することができる。]
[0074] そして、本発明による他の実施例によれば、伝送調節テーブル６５は、ネットワークの帯域幅別に各メディアを伝送するか否かを選択するための伝送選択情報を含むことができる。]
[0075] よって、制御部６０は、リッチメディアに含まれる各メディアの重要度を判別し、ネットワークの帯域幅情報及び伝送調節テーブル６５の上記伝送選択情報に基づいて、メディア処理部３３から出力される少なくとも１つのメディアのうち重要度の低い少なくとも１つのメディアを除去してリッチメディアとしてエンコーディングするようにリッチメディアエンコーディング部３６を制御できる。これにより、リッチメディアエンコーディング部３６は、メディア処理部３３から出力されるメディアのうち重要度の低い少なくとも１つのメディアを省略し、残りのもの、つまり重要度の相対的に高いメディアを合成してリッチメディアとしてエンコーディングしインターフェース部２０へ出力する。]
[0076] ここで、制御部６０は、各メディアの重要度を判別するにあたって、リッチメディアに含まれるそれぞれのメディアに対して、リッチメディアの構成において必須要素なのか否か（例：必須＝０、必須でない＝１）、リッチメディアで表示される持続時間、再伝送の可・不可（例：再伝送不可能＝０、再伝送可能＝１）、上記それぞれのメディアを参考にしたり活用する参照メディアの個数（例：３個以上＝２、２個又は１個＝１、無し＝０）、及び製作者が製作当時に上記それぞれのメディアに対して指定した製作者指定重要度（例：非常に重要＝２、重要＝１、重要でない＝０）のうちの少なくとも１つに基づいて判別できる。ここで、各メディアのアップロードを製作者より受けてそれぞれのメディアを所定のリッチメディア生成ルーチンによって合成し１つのリッチメディア画面に生成する過程を行ないながら、リッチメディアサーバー１００の制御部６０は、各メディアの必須該否、持続時間、再伝送の可・不可、参照メディアの個数、及び製作者指定重要度が分かる。]
[0077] ここで、制御部６０が各メディアの重要度を判別するための優先順位指数算出数式は次の通りである（ここで、Ｗ１〜Ｗｎ、ｆ１〜ｆｎは、各変数に対する重要度計算関数である）。]
[0078] 優先順位指数＝｛Ｗ１（持続時間）＋Ｗ２（参照メディアの個数）＋Ｗ３（製作者指定重要度）｝＊ｆ１（必須該否）＊ｆ２（再伝送の可・不可）]
[0079] よって、制御部６０は、リッチメディアに含まれる各メディアの優先順位指数を算出して、優先順位指数が高いほど該当メディアの重要度が高いものと判別することが望ましい。]
[0080] 従って、本発明によるリッチメディア伝送システムは、リッチメディアサーバー１００が制限された帯域幅を持つネットワークを通してリッチメディアを伝送する時、ネットワーク帯域幅を考慮して重要度の低い少なくとも１つのメディアを省略して重要度の相対的に高いメディアのみでリッチメディアを生成／伝送することにより、ネットワークの帯域幅に合わせてリッチメディアの伝送容量を調節し重要な情報を遅延や損失無しに適応的に端末装置１０へ提供できる。]
[0081] また、本発明によるまた他の実施例によれば、伝送調節テーブル６５は、ネットワークを通してのリッチメディアの伝送が遅れる伝送遅延時間の限界遅延時間情報を含むことができる。]
[0082] よって、制御部６０は、リッチメディアを端末装置１０へ伝送するためのネットワークの伝送遅延時間を把握し、現在伝送遅延時間が伝送調節テーブル６５の限界遅延時間情報以上である場合、リッチメディアに含まれる各メディアの重要度を判別して、メディア処理部３３から出力される少なくとも１つのメディアのうち重要度の高いメディアから重要度の低いメディアの順にエンコーディングして順次に出力するようにリッチメディアエンコーディング部３６を制御できる。これにより、リッチメディアエンコーディング部３６は、メディア処理部３３から出力されるメディアのうち重要度の高い重要メディアを、重要度の低いメディアの伝送に先立って優先的にエンコーディングしインターフェース部２０へ出力する。]
[0083] ここで、制御部６０がネットワークの伝送遅延時間を把握することは、リッチメディアサーバー１００が端末装置１０へ送信した所定の信号に対する端末装置１０からのＡＣＫ信号に基づいて伝送遅延時間を把握するなど、一般的に従来開示されている遅延時間把握方式で実行可能である。]
[0084] また、伝送調節テーブル６５は、ネットワークの伝送遅延時間帯別にメディアを伝送するか否かを選択するための伝送選択情報を含むことができる。]
[0085] よって、制御部６０は、リッチメディアを端末装置１０へ伝送するためのネットワークの伝送遅延時間を把握して、現在伝送遅延時間及び伝送調節テーブル６５の上記伝送選択情報に基づき、メディア処理部３３から出力される少なくとも１つのメディアのうち重要度の低い少なくとも１つのメディアを除去してリッチメディアとしてエンコーディングするようにリッチメディアエンコーディング部３６を制御できる。これにより、リッチメディアエンコーディング部３６は、メディア処理部３３から出力されるメディアのうち重要度の低い少なくとも１つのメディアを省略して、残りのもの、つまり重要度が相対的に高いメディアを合成しリッチメディアとしてエンコーディングしてインターフェース部２０へ出力する。]
[0086] ここで、制御部６０がリッチメディアに含まれる各メディアの重要度を判別する過程は、上記の実施例による判別過程と同様なので、その具体的な説明は省略する。]
[0087] 上述のように、本発明によるリッチメディア伝送システムは、リッチメディアサーバー１００が端末装置１０へリッチメディアを伝送するにあたって伝送遅延が酷い場合、リッチメディアを構成する各メディアのうち重要メディアから優先的に伝送することにより、伝送遅延に備えて重要な情報を遅延や損失無しに適応的に端末装置１０へ提供できる。]
[0088] また、本発明によるリッチメディア伝送システムは、リッチメディアサーバー１００が端末装置１０へリッチメディアを伝送するにあたって制限された帯域幅を持つネットワークにより発生する伝送遅延時間を考慮して重要度の低い少なくとも１つのメディアを省略し重要度の相対的に高いメディアのみでリッチメディアを生成／伝送することによって、伝送遅延に備えて重要な情報を遅延や損失無しに適応的に端末装置１０へ提供できる。]
[0089] ここで、リッチメディアサーバー１００は、使用者別に好むメディアの種類情報を予め保存したり、または使用者別に以前に要請したリッチメディアの種類経歴情報を保存する使用者情報照会部５０を更に含むことができる。]
[0090] これにより、制御部６０は、上述した端末装置１０へ提供するためのリッチメディアの該当メディアをメディア処理部３３が抽出するように制御するにあたって、端末装置１０から入力される使用者識別情報に基づいて、端末装置１０で再生できるメディアのうち該当使用者への提供に適したメディアを抽出して処理するようにすることができる。]
[0091] ここで、上述した本発明の実施例では制御部６０の構成を別途に記載したが、これは一例に過ぎない。すなわち、制御部６０の構成及びその機能がリッチメディアエンコーディング部３６に含まれてもよい。]
[0092] 以上から分かるように、上述したような本発明によるリッチメディア伝送システムは、リッチメディアサーバー１００が制限された帯域幅を持つネットワークを通してリッチメディアを伝送する時、ネットワーク帯域幅を考慮しメディアのビット率を調節してリッチメディアを生成したり、または重要度の低い少なくとも１つのメディアを省略して重要度の相対的に高いメディアのみでリッチメディアを生成して伝送することにより、ネットワークの帯域幅に合わせてリッチメディアの伝送容量を調節し重要な情報を遅延や損失無しに適応的に端末装置１０へ提供できる。]
[0093] また、本発明によるリッチメディア伝送システムは、リッチメディアサーバー１００が端末装置１０へリッチメディアを伝送するにあたって伝送遅延が酷い場合、リッチメディアを構成する各メディアのうち重要メディアから優先的に伝送することにより、伝送遅延に備え、伝送遅延時間を考慮して伝送遅延時間帯別に重要度の低い少なくとも１つのメディアを省略して重要度の相対的に高いメディアのみでリッチメディアを生成して伝送することにより、伝送遅延に備えて重要な情報を遅延や損失無しに適応的に端末装置１０へ提供できる。]
[0094] 以下、上記のように構成された本発明のリッチメディア伝送システムにおける伝送方法のフローを簡単に説明する。ここで、説明の便宜上、前述した図１に示す構成については該当参照番号を言及して説明する。] 図１
[0095] まず、本発明のリッチメディアサーバー１００の制御部６０は、ネットワークの帯域幅別にリッチメディアの伝送容量を調節するための伝送容量情報を含む伝送調節テーブル６５を予め保存する（Ｓ１０）。そして、リッチメディアの閲覧を望む使用者が使用している端末装置１０は希望するリッチメディアを要請する（Ｓ２０）。この時、端末装置１０は、自体機種情報及び再生機情報と、使用者識別情報をリッチメディアサーバー１００へ提供することが望ましい。]
[0096] リッチメディアサーバー１００の制御部６０は、端末装置１０からリッチメディアが要請されるか否かを判断する（Ｓ３０）。リッチメディアが要請されれば、制御部６０は、メディアＤＢ４０に保存されている各メディア別の最小スペック情報に基づき、要請されたリッチメディアに該当する各メディアの最小スペック情報と、端末装置１０の機種情報及び再生機情報とを比較する（Ｓ４０）。そして、制御部６０は、端末装置１０が要請したリッチメディアを再生可能かどうかを判断し、再生可能なメディアを抽出して処理するようにメディア処理部３３を制御する（Ｓ５０）。ここで、メディア処理部３３は、端末装置１０が再生し得るメディアで構成されたリッチメディアを端末装置１０へ提供するために、該当メディアを抽出して処理する。]
[0097] この時、制御部６０は、現在端末装置１０と通信するためのネットワークの帯域幅情報を把握して、ネットワークの帯域幅情報及び伝送調節テーブル６５に基づきメディアの伝送容量を調節するようにメディア処理部３３とリッチメディアエンコーディング部３６のうちの少なくとも１つを制御する（Ｓ６０）。よって、制御部６０の制御に従い、メディア処理部３３とリッチメディアエンコーディング部３６は、ネットワークの帯域幅情報に対応して伝送容量を調節したリッチメディアを生成し端末装置１０へ出力する（Ｓ７０）。]
[0098] ここで、段階Ｓ１０で予め保存された伝送調節テーブル６５は、ネットワークの帯域幅別にメディアの伝送ビット率を調節するための伝送ビット率情報を含むこともでき、段階Ｓ６０で制御部６０は、現在ネットワークの帯域幅情報及び伝送調節テーブル６５に基づいて、ネットワークの帯域幅に該当する伝送ビット率情報に対応して各メディアのビット率を上げたり又は下げたりするようにメディア処理部３３を制御できる。これにより、メディア処理部３３は、メディアＤＢ４０から抽出した少なくとも１つのメディアを処理するにあたって、ネットワークの帯域幅が狭ければ各メディアのビット率を下げて処理してリッチメディアエンコーディング部３６へ提供し、ネットワークの帯域幅が広ければ各メディアのビット率を正常維持したりビット率を上げたりしてリッチメディアエンコーディング部３６へ提供する。]
[0099] 一方、本発明による他の実施例によれば、段階Ｓ１０で予め保存された伝送調節テーブル６５は、ネットワークの帯域幅別に各メディアを伝送するか否かを選択するための伝送選択情報を含むことができる。]
[0100] 図３（Ａ）を参照して段階Ｓ６０をより詳細に説明すれば、制御部６０は、リッチメディアに含まれる各メディアの重要度を判別して（Ｓ６１）、ネットワークの帯域幅情報及び伝送調節テーブル６５の上記伝送選択情報に基づき、メディア処理部３３から出力される少なくとも１つのメディアのうち重要度の低い少なくとも１つのメディアを除去してリッチメディアとしてエンコーディングするようにリッチメディアエンコーディング部３６を制御する（Ｓ６２）。これにより、リッチメディアエンコーディング部３６は、メディア処理部３３から出力されるメディアのうち重要度の低い少なくとも１つのメディアを省略して、残りのもの、つまり重要度が相対的に高いメディアを合成してリッチメディアとしてエンコーディングしインターフェース部２０へ出力する。] 図３
[0101] ここで、段階Ｓ６１で制御部６０が各メディアの重要度を判別することは、リッチメディアに含まれるそれぞれのメディアに対して、リッチメディアの構成において必須要素なのか否か（例：必須＝０、必須でない＝１）、リッチメディアで表示される持続時間、再伝送の可・不可（例：再伝送不可能＝０、再伝送可能＝１）、上記それぞれのメディアを参考にしたり活用する参照メディアの個数（例：３個以上＝２、２個又は１個＝１、無し＝０）、及び製作者が製作当時に上記それぞれのメディアに指定した製作者指定重要度（例：非常に重要＝２、重要＝１、重要でない＝０）のうちの少なくとも１つに基づいて行なうことができる。]
[0102] ここで、各メディアのアップロードを製作者より受けてそれぞれのメディアを所定のリッチメディア生成ルーチンに従って合成して１つのリッチメディア画面に生成する過程を行いながら、リッチメディアサーバー１００の制御部６０は、各メディアについて、必須該否、持続時間、再伝送の可・不可、参照メディアの個数、及び製作者指定重要度が分かる。
制御部６０が各メディアの重要度を判別するための優先順位指数算出数式は次の通りである（ここで、Ｗ１〜Ｗｎ、ｆ１〜ｆｎは各変数に対する重要度計算関数である）。]
[0103] 優先順位指数＝｛Ｗ１（持続時間）＋Ｗ２（参照メディアの個数）＋Ｗ３（製作者指定重要度）｝＊ｆ１（必須該否）＊ｆ２（再伝送の可・不可）]
[0104] よって制御部６０は、リッチメディアに含まれる各メディアの優先順位指数を算出し、優先順位指数が高いほど該当メディアの重要度が高いものと判別することが望ましい。]
[0105] 一方、本発明によるまた他の実施例によれば、段階Ｓ１０で予め保存された伝送調節テーブル６５は、ネットワークを通してのリッチメディアの伝送が遅れる伝送遅延時間の限界遅延時間情報を含むことができる。]
[0106] よって、図３（Ｂ）を参照して段階Ｓ６０をより詳しく説明すれば、制御部６０は、リッチメディアに含まれる各メディアの重要度を判別する（Ｓ６４）。そして、制御部６０は、リッチメディアを端末装置１０へ伝送するためのネットワークの伝送遅延時間を把握し、現在伝送遅延時間が伝送調節テーブル６５の限界遅延時間情報以上なのかどうかを判断する（Ｓ６６）。伝送遅延時間が限界遅延時間情報以上である場合、制御部６０は、メディア処理部３３から出力される少なくとも１つのメディアのうち重要度の高いメディアから重要度の低いメディアの順にエンコーディングして順次に出力するようにリッチメディアエンコーディング部３６を制御する（Ｓ６８）。よって、リッチメディアエンコーディング部３６は、メディア処理部３３から出力されるメディアのうち重要度の高い重要メディアを、重要度の低いメディアの伝送に先立って優先的にエンコーディングしてインターフェース部２０へ出力する。] 図３
[0107] 以上から分かるように、上述したような本発明によるリッチメディア伝送方法は、リッチメディアサーバー１００が制限された帯域幅を持つネットワークを通してリッチメディアを伝送する時、ネットワーク帯域幅を考慮の上でメディアのビット率を調節してリッチメディアを生成したり、または重要度の低い少なくとも１つのメディアを省略して重要度の相対的に高いメディアのみでリッチメディアを生成し伝送することにより、ネットワークの帯域幅に合わせてリッチメディアの伝送容量を調節し重要な情報を遅延や損失無しに適応的に端末装置１０へ提供することができる。]
[0108] また、本発明によるリッチメディア伝送方法は、リッチメディアサーバー１００が端末装置１０へリッチメディアを伝送するにあたって伝送遅延が酷い場合、リッチメディアを構成する各メディアのうち重要メディアから優先的に伝送することにより、伝送遅延に備えて重要な情報を遅延や損失無しに適応的に端末装置１０へ提供できる。]
[0109] 図４は、図１に示す重要度基盤のメディア提供システムの動作過程を示す順序図である。図４に一例として示された通り、重要度基盤のメディア提供方法は、端末装置１０がメディア提供基盤のサービスを要請するためにリッチメディアサーバー１００に接続することから進行される（Ｓ１００）。] 図１ 図４
[0110] 以後、リッチメディアサーバー１００は、端末装置１０から提供された端末情報を用いて予め保存されているメディア関連データベースに基づき端末装置１０に対応するメディア再生情報を抽出し（Ｓ１０２）、抽出したメディア再生情報を基にサービス提供のための少なくとも１つ以上のメディアを抽出する（Ｓ１０４）。]
[0111] 次に、上記段階Ｓ１０４で抽出した少なくとも１つ以上のメディアに対して、上記端末装置１０を通して実行されるためのメディア提供基盤のサービスにおいてその重要度がどれぐらいであるかを判別する（Ｓ１０６）。]
[0112] 上記段階Ｓ１０６での判別の結果、上記少なくとも１つ以上のメディアが重要レベルのメディアであると確認されれば、これに対応して伝送プロトコルを設定し、上記少なくとも１つ以上のメディアと関連したエラー訂正コードの量を通信帯域幅によって増やして割当てた後（Ｓ１０８及びＳ１１０）、このように伝送コーディングの変換された上記少なくとも１つ以上のメディアを端末装置１０へ伝達する（Ｓ１１２）。]
[0113] その後、端末装置１０は、伝送コーディングの変換された上記少なくとも１つ以上のメディアの提供を受けて該当エラーに対する復旧を実行し、復旧されたメディアを再生するようになる（Ｓ１１４）。]
[0114] 今まで本発明を望ましい実施例を参照して詳細に説明したが、本発明は上記の実施例に限定されるものではなく、以下の特許請求の範囲にて請求する本発明の要旨を逸脱しない範囲内で、本発明の属する技術分野における通常の知識を持つ者ならば誰でも様々な変形または修正が可能な範囲まで本発明の技術的思想が及ぶと言えよう。]
[0115] 本発明は、メディア提供基盤のサービスの提供を受けるために接続する使用者端末装置に応答するサーバーが、使用者端末装置に対するメディア再生関連データを基に該当する少なくとも１つ以上のメディアを抽出した後、メディア提供基盤のサービスを実行したり、使用者のサービス利用パターン（形態）などを考慮して抽出した少なくとも１つ以上のメディアに対する重要度を判別して、それぞれの重要度別に分類されるメディアに対応して差別化された伝送プロセッシングを実行し使用者端末装置に伝達するためのものであるため、市販または営業の可能性が充分なだけでなく、現実的に明白に実施可能な程度であるから産業上利用可能性がある発明である。]

权利要求:

請求項1
ネットワークを通してリッチメディアを伝送するリッチメディアサーバーにおいて、リッチメディアを要請する端末装置と通信するためのインターフェース部；上記要請に対応する少なくとも１つのメディアを処理するメディア処理部；上記メディア処理部から出力される少なくとも１つのメディアを上記端末装置へ提供するためにリッチメディアとしてエンコーディングして上記インターフェース部に出力するリッチメディアエンコーディング部；及び上記リッチメディアの再生情報に基づき上記リッチメディアを構成するメディアに対する重要度を判別して、上記重要度判別結果を基に上記少なくとも１つ以上のメディアに対する伝送プロセッシングを変換するように上記メディア処理部と上記リッチメディアエンコーディング部のうち少なくとも１つを制御する制御部；を含むことを特徴とするリッチメディアサーバー。
請求項2
上記制御部は、上記リッチメディアに含まれるそれぞれのメディアに対して、上記リッチメディアの構成において必須要素なのか否か、上記リッチメディアで表示される持続時間、再伝送の可・不可、上記それぞれのメディアを参考にしたり活用する参照メディアの個数、及び製作者が製作当時に指定した製作者指定重要度のうちの少なくとも１つに基づいて上記それぞれのメディアの重要度を判別することを特徴とする請求項１に記載のリッチメディアサーバー。
請求項3
上記制御部は、下記のような優先順位指数算出数式：優先順位指数＝｛Ｗ１（持続時間）＋Ｗ２（参照メディアの個数）＋Ｗ３（製作者指定重要度）｝＊ｆ１（必須該否）＊ｆ２（再伝送の可・不可）に基づいて上記リッチメディアに含まれる各メディアの優先順位指数を算出し、上記優先順位指数が高いメディアを重要度が高いものと判別し、ここで、Ｗ１〜Ｗｎ、ｆ１〜ｆｎは、各変数に対する重要度計算関数であることを特徴とする請求項２に記載のリッチメディアサーバー。
請求項4
上記制御部は、上記ネットワークの帯域幅別に上記リッチメディアの伝送容量を調節するための伝送容量情報を含む伝送調節テーブルを予め保存し、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づいて上記メディアの伝送容量を調節することを特徴とする請求項１に記載のリッチメディアサーバー。
請求項5
上記伝送調節テーブルは、上記ネットワークの帯域幅別に上記メディアの伝送ビット率を調節するための伝送ビット率情報を含み、上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づいて上記メディアのビット率を調節するように上記メディア処理部を制御することを特徴とする請求項４に記載のリッチメディアサーバー。
請求項6
上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づき、上記ネットワークの帯域幅に該当する上記伝送ビット率情報に対応して上記メディアのビット率を上げたり下げたりするように上記メディア処理部を制御することを特徴とする請求項５に記載のリッチメディアサーバー。
請求項7
上記伝送調節テーブルは、上記ネットワークの帯域幅別に上記メディアを伝送するか否かを選択するための伝送選択情報を含み、上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルの上記伝送選択情報に基づき、上記メディア処理部から出力される少なくとも１つのメディアのうち重要度の低い少なくとも１つのメディアを除去して上記リッチメディアとしてエンコーディングするように上記リッチメディアエンコーディング部を制御することを特徴とする請求項４に記載のリッチメディアサーバー。
請求項8
上記伝送調節テーブルは、上記ネットワークを通しての上記リッチメディアの伝送が遅れる伝送遅延時間の限界遅延時間情報を含み、上記制御部は、上記ネットワークの伝送遅延時間が上記伝送調節テーブルの限界遅延時間情報以上である場合、上記メディア処理部から出力される少なくとも１つのメディアのうち重要度が高いメディアから重要度が低いメディアの順にエンコーディングして順次に出力するように上記リッチメディアエンコーディング部を制御することを特徴とする請求項４に記載のリッチメディアサーバー。
請求項9
上記制御部は、重要度判別結果に応じて上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を調節することを特徴とする請求項４に記載のリッチメディアサーバー。
請求項10
上記制御部は、上記少なくとも１つ以上のメディアが重要レベルのメディアである場合、上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を通信帯域幅に対応して増やすことを特徴とする請求項９に記載のリッチメディアサーバー。
請求項11
上記制御部は、上記少なくとも１つ以上のメディアが重要でないレベルのメディアである場合、上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を通信帯域幅に対応して減らすことを特徴とする請求項９に記載のリッチメディアサーバー。
請求項12
上記制御部は、上記エラー訂正コードを含む少なくとも１つ以上のメディアに対する伝送率をモニターリングし、モニターリング結果を基に生成される伝送ビット率調節信号に基づき上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を再調節することを特徴とする請求項９に記載の重要度基盤のメディア提供システム。
請求項13
ネットワークを通してリッチメディアを要請する端末装置；及び上記端末装置と通信するためのインターフェース部と、上記要請に対応する少なくとも１つのメディアを処理するメディア処理部と、上記メディア処理部から出力される少なくとも１つのメディアを上記端末装置へ提供するためにリッチメディアとしてエンコーディングして上記インターフェース部に出力するリッチメディアエンコーディング部と、上記リッチメディアの再生情報に基づいて上記リッチメディアを構成するメディアに対する重要度を判別し、上記重要度判別結果を基に上記少なくとも１つ以上のメディアに対する伝送プロセッシングを変換するように上記メディア処理部と上記リッチメディアエンコーディング部のうち少なくともどちらか１つを制御する制御部とを含むリッチメディアサーバー；を含んでなることを特徴とするリッチメディア伝送システム。
請求項14
上記制御部は、上記リッチメディアに含まれるそれぞれのメディアに対して、上記リッチメディアの構成において必須要素なのか否か、上記リッチメディアで表示される持続時間、再伝送の可・不可、上記それぞれのメディアを参考にしたり活用する参照メディアの個数、及び製作者が製作当時に指定した製作者指定重要度のうちの少なくとも１つに基づいて上記それぞれのメディアの重要度を判別することを特徴とする請求項１３に記載のリッチメディア伝送システム。
請求項15
上記制御部は、下記のような優先順位指数算出数式：優先順位指数＝｛Ｗ１（持続時間）＋Ｗ２（参照メディアの個数）＋Ｗ３（製作者指定重要度）｝＊ｆ１（必須該否）＊ｆ２（再伝送の可・不可）に基づいて、上記リッチメディアに含まれる各メディアの優先順位指数を算出し上記優先順位指数が高いメディアを重要度が高いものと判別し、ここで、Ｗ１〜Ｗｎ、ｆ１〜ｆｎは、各変数に対する重要度計算関数であることを特徴とする請求項１４に記載のリッチメディア伝送システム。
請求項16
上記制御部は、上記ネットワークの帯域幅別に上記リッチメディアの伝送容量を調節するための伝送容量情報を含む伝送調節テーブルを予め保存し、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づいて上記メディアの伝送容量を調節することを特徴とする請求項１３に記載のリッチメディア伝送システム。
請求項17
上記伝送調節テーブルは、上記ネットワークの帯域幅別に上記メディアの伝送ビット率を調節するための伝送ビット率情報を含み、上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づいて上記メディアのビット率を調節するように上記メディア処理部を制御することを特徴とする請求項１６に記載のリッチメディア伝送システム。
請求項18
上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルに基づいて、上記ネットワークの帯域幅に該当する上記伝送ビット率情報に対応して上記メディアのビット率を上げたり下げたりするように上記メディア処理部を制御することを特徴とする請求項１７に記載のリッチメディア伝送システム。
請求項19
上記伝送調節テーブルは、上記ネットワークの帯域幅別に上記メディアを伝送するか否かを選択するための伝送選択情報を含み、上記制御部は、上記ネットワークの帯域幅情報及び上記伝送調節テーブルの上記伝送選択情報に基づいて上記メディア処理部から出力される少なくとも１つのメディアのうち重要度が低い少なくとも１つのメディアを除去して上記リッチメディアとしてエンコーディングするように上記リッチメディアエンコーディング部を制御することを特徴とする請求項１６に記載のリッチメディア伝送システム。
請求項20
上記伝送調節テーブルは、上記ネットワークを通しての上記リッチメディアの伝送が遅れる伝送遅延時間の限界遅延時間情報を含み、上記制御部は、上記ネットワークの伝送遅延時間が上記伝送調節テーブルの限界遅延時間情報以上である場合、上記メディア処理部から出力される少なくとも１つのメディアのうち重要度の高いメディアから重要度の低いメディアの順にエンコーディングして順次に出力するように上記リッチメディアエンコーディング部を制御することを特徴とする請求項１６に記載のリッチメディア伝送システム。
請求項21
上記制御部は、重要度判別結果に応じて上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を調節することを特徴とする請求項１６に記載のリッチメディア伝送システム。
請求項22
上記制御部は、上記少なくとも１つ以上のメディアが重要レベルのメディアである場合、上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を通信帯域幅に対応して増やすことを特徴とする請求項２１に記載のリッチメディア伝送システム。
請求項23
上記制御部は、上記少なくとも１つ以上のメディアが重要でないレベルのメディアである場合、上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を通信帯域幅に対応して減らすことを特徴とする請求項２１に記載のリッチメディア伝送システム。
請求項24
上記制御部は、上記エラー訂正コードを含む少なくとも１つ以上のメディアの伝送率をモニターリングし、モニターリング結果を基に生成される伝送ビット率調節信号に基づき上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を再調節することを特徴とする請求項２１に記載のリッチメディア伝送システム。
請求項25
上記リッチメディアサーバーは、上記端末装置の要請に対応する上記リッチメディアを提供するための少なくとも１つのメディアと上記メディアを再生可能な端末装置の最小スペック情報を予め保存するメディアデータベースを更に含むことを特徴とする請求項１３に記載のリッチメディア伝送システム。
請求項26
上記端末装置は、上記リッチメディアサーバーに対して上記リッチメディアを要請する時、上記端末装置自体の機種情報と、上記リッチメディアを再生する再生機情報とを上記リッチメディアサーバーに提供することを特徴とする請求項２５に記載のリッチメディア伝送システム。
請求項27
上記制御部は、上記端末装置から提供される機種情報及びリッチメディア再生機情報と、上記要請されたリッチメディアに該当する各メディアの上記最小スペック情報とを比較して、上記端末装置が上記リッチメディアを再生可能かどうかを判断し、再生可能なメディアで上記リッチメディアを生成するように上記メディア処理部を制御することを特徴とする請求項２６に記載のリッチメディア伝送システム。
請求項28
（イ）リッチメディアサービスを要請する使用者端末装置に応答する段階；（ロ）上記要請に対応するメディア再生情報を抽出し、上記メディア再生情報に基づき上記メディア提供基盤のサービスに対応する少なくとも１つ以上のメディアを抽出してリッチメディアとしてエンコーディングする段階；（ハ）上記リッチメディアを構成するメディアに対する重要度を判別する段階；及び（ニ）重要度判別結果を基に上記少なくとも１つ以上のメディアに対する伝送プロセッシングを変換して上記使用者端末装置に伝達する段階；を含むことを特徴とする重要度基盤のメディア提供方法。
請求項29
上記（ハ）段階は、上記メディア提供基盤のサービスにおいて必須要素なのか否か、上記使用者端末装置で再生される持続時間、関連した参照メディアの個数、メディアの製作段階で指定された重要レベル指数、及びメディア伝送環境によって上記少なくとも１つ以上のメディアが流失され上記使用者端末装置から再伝送の要請があった場合に再伝送が可能かどうかのうちの少なくとも１つ以上から、上記少なくとも１つ以上のメディアに対する重要度を判別することを特徴とする請求項２８に記載の重要度基盤のメディア提供方法。
請求項30
上記（ニ）段階は、重要度判別結果に応じて上記少なくとも１つ以上のメディアに対するエラー訂正コードの量を調節したり伝送プロトコルを設定することを特徴とする請求項２８に記載の重要度基盤のメディア提供方法。